Roughly two out of every three tech conference session demos fail — that’s according to experienced attendee and presenter Greg Low, who has seen it all happen first-hand. That means simply having your demo work as planned puts you ahead of most speakers at events like Microsoft Ignite, SAP TechEd, or PASS Summit.

Greg’s guide breaks down the specific habits — from setting realistic content goals to recording video backups of every demo — that separate presenters who recover smoothly from technical failure from those who derail their entire session trying to fix it live.

When I attend events like SAP TechEd, Microsoft Build, or Microsoft Ignite, I – like many people – usually find the networking time more valuable than the session time. There’s a pretty tight limit on the number of sessions you can attend, no matter how hard you try, so I often watch the sessions ‘on-demand’ later.

At one of the earliest TechEd Australia events I attended, they gave us DVDs of the TechEd USA sessions. That was great because it had around 250 sessions, over 150 of which I would have loved to attend in person.

A big listen

I was doing a lot of driving to/from client sites at the time, so had a lot of available listening time. I dragged the audio out of all the TechEd session videos and just listened to them. Then, if a session really interested me, I’d go back and watch the video and demos later.

That year, I listened to/watched around 150 sessions. While it was intense and interesting, there was something I wasn’t expecting – something that completely stunned me. I heard the presenters apologizing for demo failures in close to 100 of those sessions. I found that really, really hard to believe.

Yes, the demos failed in 2/3 of the sessions.

This made me determined to never get into that situation – or at least, do my very best to avoid it – when I was presenting any sort of session at events like these.

So, with that in mind – knowing that having your session demonstrations working as planned already puts you in the top third of all sessions – what can you do to ensure you’re on the right side of that equation? Whether you’re set to present at a local user group, a PASS Summit, a Day of Data/SQL Saturday, or even a Microsoft Ignite, here’s my advice.

Set realistic goals for the amount of content you have

I normally aim to tell people three things in a session. They certainly won’t remember more than that. Plus, it’s the stories they’ll remember, anyway – so make sure that each demo has a good story associated with it. And, if showing any one of these three things takes more than about 15 to 20 minutes, try again.

To the latter point, Blaise Pascal once said, “I would have written a shorter letter, but I did not have the time.” That’s short for: plan the content, and tell the story succinctly.

Plan your timing, too – it’s hard work to get just the right message in the right amount of time. I’ve lost count of how many sessions I’ve been to where the presenter ran out of time or failed to make one of the key points. Don’t be one of them.

You’ll be especially sorry if your session description includes content that you don’t end up covering as you ran out of time. Remember – someone might have come just for that content.

Aim for repeatable, and achievable, outcomes

I’ve seen so many demos that would probably only ever work with the moon in the correct position and the presenter holding his/her head the right way. Stay realistic with what you want to achieve from a demo.

Have a clear session structure (and it’s not just about demos)

There’s perceived wisdom that sessions should be comprised entirely of demos. I don’t buy it as the only rule. I’ve been to brilliant sessions with no demos, and I’ve been to horrid sessions full of demos delivered by amazing people, but they were just lacking structure in what they were trying to show.

Practice both the session and the demos

And practice them multiple times! The bigger the event, the more the entire session needs to be second nature to you. Try to deliver the session at smaller venues first. Local user groups, virtual sessions, etc. are good options for this.

Find another presenter as a critical friend

I have friends who are talented presenters and I love having them in the room for trial runs so they can deliver constructive but critical feedback. Someone that just says “yeah, that was great”, is nice, but not necessarily helpful.

Someone that says “you lost me in the second part of the demo”, however, or “I think the third demo would work better if you…” , is what you need. And be prepared to do the same for them.

Record the demos

When presenting at large events, I have a series of screenshots saved on a USB key, and I also have a full video walkthrough of each of the demos. I’m determined for the audience to see every demo in their entirety, no matter what happens.

For a simple example of when this has saved me, I look back some years ago to some Azure-related sessions I was presenting at TechEd Australia. Unfortunately for me, the Azure folk had decided to do maintenance and take things offline right in the middle of the event!

I told the audience, switched across to the videos of each demo (which I did a live voice-over for), and I suspect that many of them quickly forgot they were just watching a video. By comparison, I attended several other Azure-related sessions at that same event and watched presenter after presenter stumbling when things didn’t work. You always need a fallback plan.

Hint: Don’t just play the video with voice, etc. as well though – make it still pretty much a live thing. I’ve seen sessions where people just play a video with sound and it often looks like they could never have actually done the demo, particularly if it’s someone else’s voice – and even worse if it’s really fast.

Don’t try to debug an issue ‘live’ in-session (unless it’s a coding session)

Unless it’s an obvious and trivial issue, you’ll do far more damage trying to debug it live during your session. Attendees hate watching you stuff around trying to fix issues. You might feel great if you ever get it solved, but you will have disrupted your session’s timing and possibly looked really, really bad in the process. And if you can’t solve it, you will have really messed up. Instead, just move on and revert to your backup plan.

Conclusion: isn’t this what everyone does?

It seems pretty basic to do these things but time and again, I see the opposite – even at major events. I watched AzureConf a while back, for example, and even the keynote had some of these issues. Having been involved in event keynotes and knowing what level of rehearsal normally goes into them, I can just imagine the discussions that went on later. They wouldn’t have been pretty.

You can avoid potential disaster and embarrassment with just a bit of planning. And, by doing so, you’ll already be ahead of the pack.